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We had the money, and we thought we knew 
how to do this thing — but our flawed cash flow plan 
stood between a successful project and us. 


Dr Kenneth L. Atkins, from his “Mr. Stardust's Wild Ride" (p 16) 
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Welcome to the Academy of Program and Project 
Leadership (APPL) and ASK Magazine. APPL helps 
NASA managers and project teams accomplish today’s 
missions and meet tomorrow’s challenges by providing 
performance enhancement services and tools, supporting 
career development programs, sponsoring knowledge 
sharing events and publications, and creating opportu- 
nities for project management collaboration with univer- 
sities, professional associations, industry partners, and 
other government agencies. 

ASK Magazine grew out of APPL’s Knowledge 
Sharing Initiative. The stories that appear in ASK are 
written by the “best of the best’’ project managers, 
primarily from NASA, but also from other government 
agencies and industry. These stories contain genuine 
nuggets of knowledge and wisdom that are transferable 
across projects. Who better than a project manager to 
help another project manager address a critical issue on a 
project? Big projects, small projects — they're all here in ASK. 

Please direct all inquiries about ASK Magazine editorial 
policy to Todd Post, EduTech Ltd., 8455 Colesville Rd., 
Suite 930, Silver Spring, MD 20910, (301) 585-1030; or 
email to tpost@edutechltd.com. 
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IN THIS ISSUE Todd Post 


One-of-a-Kind, Two Ways 


Though each issue of ASK Magazine addresses the concerns of project 
management , this issue ; like all previous issues , fs a one-of-a-kind product fdled 
with the unique and often innovative insights of individual project practitioners 


In that way, we feel a kinship with Ames Research 
Center technologist Dan Gundo, who builds one-of-a- 
kind hardware for NASA projects and has given us a 
story about one. In "The Clock Is Ticking,” Gundo 
writes about an exercise bed he built for space scientists 
studying ways to counter the atrophying effects of 
microgravity on human muscles. The novelty of the 
exercise bed is only part of what we think you'll find 
interesting in the stone Best of all is how Gundo learned 
to work with his customer to define project require- 
ments clearly enough and early enough to allow him to 
meet a challenging deadline. 

Requirements challenges come up in another story', 
"Enough is Enough," by James Barrowman. On the Rossi 
X-Ray Timing Explorer mission, Barrowman worked 
with the science team to put down on paper what consti- 
tuted “good enough” science before development work 
on the spacecraft began. This looked prescient when a 
technical problem emerged, and suddenly the scientists 
forgot about what was good enough. 

This story is not the first to appear by Barrowman in 
ASK. In Issue 3, we featured his story “Pin the Deputy’s 
Badge on Me" about doing double duty as program 
manager and deputy project manager in the Explorer 
Program Office at Goddard Space Flight Center. You can 
read Barrowntan's other story by going to the ASK 
archives on our Web site. 

Donald Margolies is also making a repeat appear- 
ance in the magazine. We featured a story by Margolies in 
Issue 9 about an episode on the Advanced Composition 
Explorer (ACE) mission, for which he was project 
manager. In the interview you’ll find in this issue, 
Margolies invokes examples from ACE to discuss the 
challenges of scheduling. After reading the interview, you 
may want to read more about ACE. Again, visit our Web 
site and you'll find several stories about ACE in Issue 9. 


If it sounds as though I’m pushing our Web site, 
then I guess it’s because I am. After several issues not 
having a Web companion to our print edition, ASK is 
back online at appl.nasa.gov/ask. 

We’ve taken advantage of being part of the expansive 
NASA portal to introduce many new features. For 
example, in this print issue we’ve collected several lessons 
learned from retired Goddard project manager Jerry 
Madden. These lessons first appeared in 1995 when Jerry 
released his underground cult classic, “A Project 
Manager’s Lessons Learned.” We’ve pulled together some 
of our favorite here from the 128 Madden collected. If you 
want to read all of the lessons and you don’t have a well- 
connected friend with the original copy of the lessons, you 
can find them all on the ASK Web site. And by the way, 
you can also read an interview we did with Madden that 
appeared in Issue 4. 

What else this issue? In early 2004, a NASA space- 
craft will intersect a comet and return home in 2006 with 
some microscopic particles of stardust, another one-of- 
a-kind mission. This is the subject of Jet Propulsion 
Laboratory project manager Ken Atkins' story “Mr. 
Stardust’s Wild Ride.” The spacecraft is presently on its 
way to rendezvous with Comet Wild II, but Atkins will 
tell you how precipitously close the project came to an 
early demise. This story will be a jolt to anyone who 
thinks the only money issue that matters on a project is 
how much you get. Atkins shows that when the money 
arrives can be just as important. 

There is plenty more good stuff in Issue 14, so go 
ahead and dive in. • 
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REVIEW BOARD 


JOHN BRUNSON of the Marshall Space Flight Center is a 
member of the NASA Program Management 
Council Working Group. He served as project 
manager for three separate microgravity 
payloads that flew on various Spacelab 
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in 1 980 as a technician working on the first Space Shuttle. 
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Space Center. She has over twenty years 
experience in aerospace spanning engineering, 
R&D and project management. She is on the 
Florida Tech Engineering Accreditation Board, 
the National Fire Protection Association's Technical Committee 
for Halon Alternatives, and the United Nations Environmental 
Programme Halon Technical Options Committee. 

HECTOR DELGADO is Division Chief of Process Tools and 
Techniques in the Safety', Health and 
Independent Assessment Directorate at the 
Kennedy Space Center. In 1995, he served as 
Senior Technical Staff to the NASA Chief 
Engineer at NASA 1 leadquarters in Washington, 
D.C. He has received many honors and awards including the 
Exceptional Service Medal, Silver Snoopy Award, and various 
achievement awards. 





DR. OWEN GADEKEN is a Professor of Engineering Management 
at the Defense Acquisition University where he 
has taught Department of Defense program 
and project managers for over twenty years. He 
retired last year from the Air Force Reserve as a 
Colonel and Senior Reservist at the Air Force 
Office of Scientific Research. He is a frequent speaker at project 
management conferences and symposia. 



DR. MICHAEL HECHT has been with NASA since 1982 at the 
Jet Propulsion Laboratory (JPL). He is project 
manager and a co-investigator for the Mars 
Environmental Compatibility Assessment 
(MECA). In his previous assignment with 
NASA’s New Millennium Program, he was 
instrumental in defining the "microlander" that was adopted as 
NASA's New Millennium Program Deep Space 2. 



DONALD MARGOLIES of the Goddard Space Flight Center was 
Project Manager for the Advanced Com- 
position Explorer (ACE) mission, launched in 
1997 and still operating successfully. He 
received the NASA Medal for Outstanding 
Leadership for his work on ACE and a NASA 
Exceptional Service Medal for the Active Magnetospheric 
Particle Tracer Explorers (AMPTE) mission. 



DR. GERALD MULENBURG is the Manager of the Aeronautics 
and Spaceflight Hardware Development 
Division at the NASA Ames Research Center. 
He has project management experience in 
airborne, spaceflight, and ground research 
projects with the Air Force, industry, and NASA, 
as Executive Director of the California Math 
Science Task Force and as Assistant Director of the Lawrence 
Hall of Science. 



He also served 


JOAN SALUTE is the Associate Director of Aerospace at Ames 
Research Center. She has managed many 
NASA projects including those involving flight 
testing of thermal protection materials, 
commercial technology, commercial applica- 
tions of remote sensing, and remote sensing 
science projects. She has been at Ames for twenty years, and was 
awarded the Sloan Fellowship to attend Stanford Graduate 
School of Business. 



HARVEY SCHABES is currently assigned to the Systems 
Management Office at the Glenn Research 
Center. He started his career with NASA in 
icing research, and since then has served in 
numerous organizations in support of the 
Space Station Program. 



CHARLIE STEGEMOELLER is Manager of the Johnson Space 
Center (JSC) Human Space Life Sciences 
Programs Office. He is responsible for the 
programmatic and tactical implementation of 
the lead center assignments for Space Medicine, 
Biomedical Research and Countermeasures, 
and Advanced Human Support Technology. He began his 
career at NASA in 1985 with JSC Comptroller's Office as a 
technical program analyst. 



JODY ZALL KUSEK is a Senior Evaluation Officer at the World 
Bank. She is currently involved in supporting 
the efforts of seven governments to move to a 
focus of performance-based management. She 
has spent many years in the area of public 
sector reform, serving the Vice President of the 
United States, the U.S. Secretary of the Interior, and the U.S. 
Secretary of Energy in the areas of Strategic Planning and 
Performance Management. 



HUGH WOODWARD is a Program Manager for Global Business 
Services with the Procter & Gamble Company. 
He served as the Chairman of the Project 
Management Institute (PMI) for consecutive 
terms in 2000 and 2001. He was elected to the 
Board of Directors in 1 996, and before being 
elected as the chair, served terms as vice chair and in several 
other key leadership roles. 
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FROM THE DIRECTOR S DESK Df. Edward HoffmcVl 


Surfs Up 


Saturday morning and / could be at the gym, doing something healthy. 
Instead, I'm sweating away as I perform surgeiy on my Dell computer 


Earlier this morning, I was utterly discombobulated 
when I turned on my computer. For some inexplicable 
reason, 1 couldn't get onto the Internet. Understand, 
Web surfing isn't a hobby for me. My time on the 
Internet is an addiction. 

I call my service provider and the help person tells 
me that the problem is my card — a 10/100 or 100/10 
something. I have to switch my card 
to an open slot. Huh? I don’t know 
how to open the computer shell. 

My helper assures me he’ll be 
here (invisible but connected) to 
help me get through it. If his grand- 
mother could be instructed to fix 
her computer over the phone, 
surely 1 can be, too. (His naivete is 
scary, but forget about that — I’m in 
good hands.) 

I get the Dell open. 1 even find 
the card. But all my slots are filled. He tells me to 
switch the cards to see if the problem is the card or the 
slot in which it’s seated. My fingers start to quiver. 
Suddenly, a thought comes screaming from my brain: 
Why am 1 here? 

The answer, I’m afraid, is a sign of the times. I 
desperately want my high-speed internet service. Crazy, I 
know, but I have become a Web junkie. I need (the key 
work here is “need’’) to read New York newspapers to 
hear about my favorite hometown teams. I need ESPN to 
tell me what's happened in the sports I follow and what's 
going to happen next. Of course, I need to check out 
NASA Watch to feel in the know. Then I need to check 
flights, since my wife Dianne and daughter Amanda are 
on a short vacation. I also need to check my e-mail for 


My fingers staid to quiver. 
Suddenly, a thought comes 
screaming from my brain: 
Why am I here? 


presentations I’ll be working with colleagues. If this isn’t 
enough, on Saturday my son Daniel and I need to play an 
on-line game with mv brother and his friends in Phoenix. 

"Place firm pressure on the cards — " 

It’s okay. Mv helper is right here. 

" — but don’t force them.'’ 

NYPost.com, ESPN, Dianne and Amanda... I’m on 
my way. I fumble to put the second 
card in it’s slot. 

It's n place! Eureka! 

1 turn on the computer and.... 
Yes, it all works. Touchdown. 
Grand slam. Happy feet! 

"Thanks, kid," I say and then I 
hang up and begin to surf. 

The Web has become a 
source for everything: work, play, 
collaboration, networking, infor- 
mation, research, stories, news, 
music, communication, decision making, pictures, 
surveys, assessments, and everything else. When the 
system goes down, I start to react like a man with a 
crack habit. 

By no small coincidence, this story coincides with 
the fact that on July 31, the APPL Web portal debuted. 
New and improved, as they say. Working with Jeanne 
Holm’s JPL team, the NASA Chief Information Office, 
and a group of brilliant Web fanatics, we’ve built an 
amazing virtual APPL. First up, ASK Magazine is again 
available online — when, where, and how you want it. 
The Web will also allow us to expand some of our ASK 
features, so keep an eye on us and enjoy. 

Be careful, however. You might just find 
appl.nasa.gov is addictive. • 
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Enough Is Enough 

by James Barrowman 


“It’s the wrong thing to be doing, ” I told the director of 
engineering, trying to head off a last minute change in our X-ray 
Timing Explorer [XTEJ project 


The spacecraft was nearly integrated and had 
passed some of its early mechanical and electrical 
testing. One of its instruments, the Proportional 
Counter Array (PCA), had a gas leak in one of the five 
proportional counter modules that made up the array. 
The science division where the instrument was being 
developed wanted a gas replenishment system added to 
assure the PCA would last for the entire mission. 

Adding a gas replenishment system would mean 
interrupting spacecraft integration and testing; devel- 
oping a new subsystem and integrating it onto the 
spacecraft; modifying all the PCA modules; including a 
complex integration of the instrument onto the space- 
craft; and implementing a more complex performance 
and environmental test process. It was the wrong answer 
because it made a simple design more complex and 
added little value to the mission at a major cost in time 
and dollars. Our mission couldn’t afford the additional 
budget and schedule risks. 

XTE was the latest of a long line of projects being 


managed by my Explorer Program Office, but it was 
unique in being the first project we had agreed to do for 
a fixed price. NASA HQ agreed, in return, to provide us 
with the funding profile we needed to make it happen. 
We were both trying to break the unhealthy spiral in the 
Explorer program that saw current missions overrun- 
ning and pushing subsequent missions downstream to 
the point where their science was becoming marginal. 
The science community was upset and wanted better 
performance from NASA. 

I summarized my arguments to the director. The 
Engineering Directorate had taken responsibility for the 
spacecraft development when we established XTE as an 
in-house project at Goddard Space Flight Center, and 
also was supporting the PCA development. 

“It adds complexity," I reiterated. "It's a significant 
cost impact for only a marginal reliability increase.” 

His response was music to my ears, "Jim, I won’t 
stand in your way, but you’ll have to convince the scien- 
tists and engineers." 
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Left: Liftoff on December 30, 1995. Middle: The XTE project team stands in front of the launch vehicle at 
Cape Canaveral. Right: The Proportional Counter Array [PCA] instrument has five xenon gas detectors used 
to study x-ray emitting objects in the Milky Way and beyond. 



Now comes the real work 

My next stop was the science division where the instru- 
ment in question was being developed. I was antici- 
pating a fight because I knew that the scientists and 
instrument engineers thought they needed the system in 
order to assure a longer life for the PCA. There was real 
disagreement on the benefits of the change and the 
impacts. Four of the PCA modules were sealed well and 
leak tests had confirmed they would last beyond two 
years. Only one module had a 
problem. None of this was outside 
the parameters of the project's basic 
requirements, and I knew that I was 
going to need to rely on those 
requirements if I was going to win 
this argument. 

I entered the fray, so to speak, 
because the XTE project manager 
had asked me to get involved. I was 
the Explorers program manager, but 
I worked with my project managers in a way that 
encouraged them to consider me their deputy. They 
gave me jobs to do that helped them out. In the process, 
1 created a stronger bond so that they didn't simply view 
me as a boss, but as somebody who supported them. The 
project manager and the spacecraft manager wanted to 
stay focused on the mission development while I fought 
the political and technical battles necessary to prevent 
disrupting progress. 

As part of our plan to pull XTE off for a fixed price, 
we worked closely with the science team to document 
the mission requirements. We struggled together to 
make the requirements specific, clear, and to the 
greatest extent possible quantitative. As a result, 
the XTE project plan identified performance require- 
ments on all the major mission elements. Two of the 


requirements bore directly on this situation: The 
mission had to last two years, and four of the five PCA 
modules had to be operative for that time period. Of 
course, the scientists’ goal was for XTE to last much 
longer than two years and to have all five PCA modules 
operating as long as possible. 

It’s important to note here that we didn't negotiate 
our requirements in isolation at the beginning of the 
project. Our requirements were well thought out and 
realistic because they were estab- 
lished after wc had taken implemen- 
tation approaches into consideration 
during initial formulation. First, the 
scientists laid out broad goals. 
Eventually, we gained an under- 
standing of the architecture, imple- 
mentation, and programmatic issues, 
and we were able to sign off on 
realistic requirements. 

Sealing the deal 

When it was time to remind people about these require- 
ments, I met with the instrument team and laid out the 
total situation, both technical and programmatic. All the 
key scientists and managers had signed the XTE project 
plan, and we supposedly had a firm and broad 
agreement on our direction and plan. “These are your 
requirements, guys," I said. “You signed up for them, and 
you agreed to them." 

I didn’t have to say it explicitly because it was clear 
what 1 was getting at: Where’s your integrity? If you didn’t 
mean this, why did you sign up for it? 

Thev weren't happy, but they agreed not to pursue 
the gas replenishment system. Our mission require- 
ments were being met. The scientists stood by their 
requirements and confirmed their understanding that we 


We were both trying to break 
the unhealthy spiral in the 
Explorer program that saw 
current missions overrunning 
and pushing subsequent 
missions downstream to the 
point where their science 
was becoming marginal. 
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had taken on this mission for a fixed 
price in response to concerns from 
the broader science community. 

Once that decision was made, 
my engineers refocused on the question of the leak. The 
instrument development team redoubled their efforts to 
seal the fifth PCA module. Eventually, they found a 
tolerance build-up and fixed it in time to get the module 
delivered on schedule. 

The XTE mission was ready on time and well within 
budget. It is now on orbit as the Rossi X-ray Timing 
Explorer (RXTE) mission in honor of astronomer Bruno 
Rossi. RXTE has dramatically improved the under- 
standing of the high-energy phenomena in the universe, 
discovered black holes at the center of galaxies, and corre- 
lated the size of black holes to the size of the galaxies. 

Not only did the mission meet its requirements, 
RXTE is still scientifically productive after seven years in 
orbit, and there has been no degradation of the PCA 


performance. The time we spent 
working with the scientists to get 
the right requirements clearly 
understood and mutually accepted 
has reaped a far greater return on investment than we 
dared to imagine. • 

Lessons 

• Clear, documented requirements help you control the 
scope of your project and resist unnecessary changes. 
Have all key parties sign off on the requirements to 
assure that they understand and are committed to them. 

• Get your project requirements right as soon as 
possible, but not prematurely. To assure they are 
realistic, requirements should not be finalized until after 
implementation approaches have been considered. 

Question 

How do you know you are done defining requirements? 


The project manager and the 
spacecraft manager wanted 
to stay focused on the mission 
development while I fought the 
political and technical battles 
necessary to prevent 
disrupting progress. 



Deputized 


As head of the Explorers Program, james barrowman oversaw the successful 
launch of eight Explorer missions in three years. In his story, “Pin the Deputy’s 
Badge on Me’’ [ ASK 3], Barrowman explained that the program’s tight resources 
inspired him to serve as deputy to the project managers working under him. “In 
addition to reducing overhead while maintaining technical positions,” Barrowman 
wrote, “I felt this would change my relationship with the project managers from 
boss to supporter.” But did it work? 


Despite competing time demands, initially “nervous and disoriented” staff, and 
occasional differences of opinion, the novel arrangement translated into a 
successfully run program. Barrowman summed up the experience this way: “In 
the end, the project managers and their staffs were satisfied, I was satisfied, 
and we were all able to operate an effective and efficient program.” 

Over the course of a 22-year career as a project and program manager at 
Goddard Space Flight Center, Barrowman received the NASA Outstanding 
Leadership Medal, the GSFC Award of Merit, and two NASA Exceptional Service 
medals. He has been a longtime supporter of APPL programs, and can be 
reached at jbarrowman@comcast.net 
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by Dan Gundo 


E Recently, I worked on creating a one-of-a-kind device for a Space 
Station group studying exercise physiology at another NASA Center. 
They approached my department at Ames Research Center to design 
and build an exercise bed that allowed users to perform the motions that 
they needed for ground-based research. The real challenge was that 
they needed the device designed, built, and delivered in just one month. 


I DREW UP ROUGH SKETCHES OF A DESIGN FOLLOWING THE 

initial plan described to me. The bed was intended to 
simulate doing squats while in a horizontal position as if 
on a moving sled. They wanted to incorporate a resistant 
device called an Interim Resistive Exercise Device (IRED), 
an adjustable cable tied into a reel to provide a measured 
amount of resistance. This device was used on the Station 
for exercising in space; we were taking the same resistant 
reel and incorporating it in this bed. 


In the early stages of a design project, I communi- 
cate with a customer as much as I can and as often as 
they will tolerate. There's a lot of learning that needs to 
go on, and 1 prefer to spend a little bit of extra time here 
because that can save a lot of time later. In the beginning, 
you need to volley the information back-and-forth, so 
that you understand the customer’s requirements and 
they know what you're capable of doing. 
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They liked my initial sketches, so I started 
adding more detail. I also started to identify 
the shopping list of materials. I explained why I recom- 
mended certain materials over others, and how I would 
go about building the bed based on the resources that I 
had available to me. We also were narrowing down the 
cost of it. All of these issues have to be considered from 
the perspective of producing a design as quickly as 
possible. This whole process I’ve described happens in a 
matter of days, sometimes even hours. 


introduce vertical motion of the hips was crucial to the 
performance of the exercise. It changed the complexity 
of the project substantially — just a couple of weeks 
before the due date. 

When my customer came back to me asking for this 
last-minute change, I knew that the responsibility was on 
my shoulders to make it happen. I wanted to build a 
product that met their needs, but I didn't quite under- 
stand the details. 

I had to know for certain, without a doubt, what they 
wanted — and there was no time in our schedule or travel 


When I'm designing something from scratch, there 
are a lot of uncertainties. In my design for the exercise, I 
implemented adjustability into the device — more than 
they had asked for initially — because I knew that people 
of different heights might need to use the bed. I put 
more travel in the foot rest when I realized that it didn’t 
have enough range. 

It’s okay to be flexible and change something many 
times while it's still a design, because it’s a heck of a lot 
easier to change your design on paper than it is to 
change things once you have metal cut, welded, and 
machined. Sometimes researchers will come up with 
another idea and another idea and another. These can 
have major ripple effects on all of the parts, pieces, and 
components of how the device is sized, shaped, and 
built. So, there comes a point when I want the customer 
to say, "Okay, I’m settled on this design. This is it. We’re 
going to move forward with it and we’re not going to 
change anything." 

From my perspective, the priority on any project is 
to deliver it on the due date. I can make the most 
wonderfully innovative device that has ever been seen on 
earth, but if I don't get it done in time for the customer 
to use it, then it's all been a waste. 


You can probably guess where this story is 
going. At the point at which I thought we 
were ready to start buying the materials and cutting 
metal, my customers introduced a significant change to 
the requirements. Somebody within their group decided 
that a counterweight to neutralize the weight and 



money in the budget to arrange a face-to-face meeting. 
To try and get that over the phone, or in a faxed sketch 
wouldn’t eliminate my doubt. So, in order to hold their 
feet to the fire on specifics, I said, "I need you guys to 
create detailed drawings and then send them to me as 
soon as possible.” 

Now, 1 don’t normally ask a customer to do the design 
work on a project, but this was a customer who had worked 
with hardware exercise devices before and who had added 
a last-minute function to the design. I wanted them to 
realize the ramifications of a change like this — hopefully, 
preempting any additional changes. I like to retain as much 
flexibility as I can during a project, but the customer has to 
understand that the manufacturing process doesn’t allow 
for ambiguity. I had to shift responsibility for finalizing the 
design to my customer at this point. 

To their credit, they stepped up and delivered the 
drawings right away. There were a few mistakes but we 
were able to make the fixes and corrections, and still 
keep moving forward. We had the idea in mind. 


When you’re doing design and fabrication on 
a unique product and you're being asked to 
deliver on a tight deadline, the project is laced with 
unknowns. The path of these projects can change at any 
time — but there is still a method to the madness. One 
thing I do is keep close track of everything that needs to 
be accomplished during the development process — from 
clarifying objectives, to sketching and sizing, to assembly. 

Throughout the years, I have developed a file where 
I keep track of sources for unique parts, tools, and 
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I wanted them to realize the ramifio 
preempting any additional changes 

instruments — things like special bearings that I don’t 
keep stocked because they're not needed often. I have 
contact information for these sorts of materials and for 
all my available vendors, so that I don't waste time trying 
to track down a part or a tool required by an eleventh- 
hour development. 

I'm also prepared to suggest trade offs when they're 
necessary to finish on schedule. For example, we planned 
to paint the frame of the bed, but we ran so short on time 
that we didn't paint it. It wasn't going to affect the 
function of the device. That was an easy compromise; 
others are more difficult. 

Initially, they wanted the frame made out of steel. 
Cutting, machining, shaping, and welding steel requires 
more time than alternative materials. Aluminum is easier 
and quicker to cut and machine. Plus, it's much lighter and 
easier to handle. It cost a little bit more money, but 1 was 
able to save time by building the frame out of aluminum. 

When you're short on time, man-hours are 
something that you can't make up. When we encountered 
some warping in the welded frame, 1 went to the 
researchers and told them, "We can still get this done if 
you'll increase the service request to support more people.” 
They agreed to it, and 1 brought in additional shop techni- 
cians to help solve the problem. They were also critical in 
addressing a last-minute problem with linear bearings. 


Hons of a change like this — hopefully, 


All projects like this one involve some degree of trial 
and error, building and rebuilding, reaching compro- 
mises, and learning from mistakes. In the end, our 
customers had to compromise slightly on cost, but we 
completed the project on time. 

In my world of designing and creating new products, 
the one constant is speed — not to mention the byproduct 
of speed: pressure. Some projects may not involve the 
same level of pressure, but when you complete a quick- 
turnaround project on time and you’ve met all of the 
challenges that at first seemed overwhelming, the reward 
also seems to be that much greater. • 

Lessons 

• When creating a unique project, customers don't 
always know the details of what they need at the start 
of a project. Close communication between the project 
team and the customer facilitates a continuous 
learning process. 

• Knowing when to be flexible and when to be firm is a 
hallmark of successful project management. 

Question 

How important is face-to-face communication when working 
with a client? 


THE UNBEARABLE LIGHTNESS OF MICR 


GRAVITY 


Ever since space missions began, NASA has worked 
to address problems caused by the deterioration of 
bone and muscle tissue due to weightlessness. One 
method for evaluating prevention and recovery treat- 
ments for this problem is to expose normally healthy 
individuals to periods of bed-rest that duplicate many of the space- 
weightlessness symptoms. Bed-rest participants remain in a prone 
position for up to thirty days without sitting up or standing. 

The exercise bed described here by Ames Research Center proto- 
typing specialist DAN GUNDO is typical of the kinds of projects he 
works on. Gundo uses a process he describes as "prototype-as- 
design" to create unique, one-of-a-kind research hardware for small, 
high-risk projects. Prototype-as-design is a highly interactive, 
integrated process that allows multiple iterations of complex aspects 
of a desired R&D product to be quickly evaluated and adapted into 
a properly functioning whole. 

This is Dan Gundo's first appearance in ASK Magazine. You can 
contact him at Daniel.P.Gundo@nasa.gov. 
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LISTENING 


TO THAT 

VOICE INSIDE 



BY DAVE STICKEL 

A few years ago, I was managing a 
project whose scope included the 
addition of several new unit operations 
to existing production lines. Part of my 
project involved adding a fabricated 
module similar to one another project 
had recently purchased on a T&M 
(Time & Material) basis from Company 
A. This company had done a good job, 
so prevailing wisdom dictated all we 
had to do for this part of the job was 
to adapt the design to our production 
lines, and go. 


Along with our procurement manager and the 
project manager of the recently completed project, 
I traveled to the vendor’s shop where these modules 
were fabricated. On the earlier project, after the bugs 
were worked out of the design, our company purchased 
more than twenty of these units. The first unit cost 
about $180,000, but as the design was tested and 
reworked, the T&M price came down to about 
$120,000 per unit for the remainder of the order. 

As soon as I walked into Company A's shop, 1 
started getting a sales pitch. The shop supervisor, who 
I knew from a previous project, said, “Well, Dave, I’d like 
to introduce you to Sam, who's going to be your fabri- 
cation and assembly manager. Any time you 
want anything, day or night, just call Sam.” He went on 
to tell me, “Here are the machines that are ready to 


chunk out all your parts the minute you tell us to start 
cutting steel.” 

1 liked what 1 saw in the shop, even without the 
sales pitch. 

And then, on top of that, our procurement manager 
and the project manager from our first project took me 
off to the side to give me their own version of the sales 
pitch. They told me that sticking with Company A’s 
current design and fabrication would make my life easier 
and would allow me to focus on other parts of my 
project. It was very tempting to think about putting this 
part of the project behind me. 

At the end of the day, we regrouped with 
Company A’s personnel in a conference room. The 
vendor's representatives said that if I would give them 
the green light, they would deliver the 50+ machines I 
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needed at about $118, 000/unit. My procurement 
manager and fellow project manager thought this was 
what I should do, but I was uneasy. It just didn't make 
sense to me. 

This particular unit operation is similar to a 
number of other unit operations throughout the 
manufacturing process, and the design for this one 
wasn’t all that dissimilar from them. I knew we had paid 
a lot less for those other unit operations. 

So I said, "I've just got to think about this." I didn't 
know exactly what I wanted to think about, but I knew I 
didn't want to make a decision right on the spot. I had a 
lot of experience making quick decisions, but something 
told me to follow my instinct that this decision required 
more consideration. In the cab to the airport and on the 
plane on the way home, I kept hearing from my two 
compatriots that I was making a big mistake by not 
accepting this offer. 

When I got home, 1 checked my phone messages. 
Company A’s shop superintendent had left me a 
message. He said, "After you left today, we got together 
and we sharpened our pencils, and we decided that we 
can do your project at about $108,000 a machine.” It 
wasn’t hard to figure out the math; we would save 
$10,000 on each of the 50 or so machines. And I said, 
"Wow! All I did was say I wanted to think about it, and I 
saved a half a million dollars." My delay of six hours was 
paying dividends. 

But I still wasn't satisfied. This unit operation 
wasn’t on the critical path of my project, so there was no 
reason I had to make the decision immediately. 1 had 
time in my schedule, and I decided to go out for compet- 
itive bidding. We bid Company A along with a number 
of other shops I was familiar with. A few weeks later, I 
received a bid from Company A for $93,000 per unit. 
But they still didn't get the job. We awarded the contract 
at $67,000 per unit to Company B, where I also knew the 
people. 

At the pre-award meeting at Company B, I said, 
"You know, I've got to be honest with you. You're the 
lowest bid. Are you confident that you understand this 
bid?” Long ago, 1 learned that it isn’t good business to 
take advantage of an underbid — because if you put 
someone out of business and they don't deliver, your 
own program suffers, too. 

They told me they were confident. And it turned 
out well. They had done their homework, and we had 
done ours in working with them and making sure they 
understood what they were getting into. 


In the end, I saved more than $2.5 million by 
following my gut instinct, which said, “I've got time to 
think about this.” I took advantage of the opportunity to 
step back even when everybody else was telling me, 
"You ought to do this right now." Because of that 
project. I've been willing to trust my instincts more. • 

Lessons 

• Many leaders who commonly use intuition are 
reluctant to talk about it. considering it too soft and 
"mystical" a process to openly acknowledge. But the 
more we share and discuss stories of decisions based on 
intuition, the more we learn about when and how to 
employ it. 

• Trusting one's intuition doesn't necessarily mean one 
has to abandon well accepted processes. 

Question 

Some people say: “ Don't listen to your intuition. Intuition is 
nothing more than justification of luck." Do you agree? 


GOT MILK? 


I In his 26 years with Procter & 
^ Gamble, DAVE STICKEL has been 
involved in capital projects as project 
manager, cost engineer, and start-up 
I leader. Currently, he serves as the 
Global Process Owner for Capital Project Management 
Technology, part of the Corporate Engineering organiza- 
tion at P&G. 

“My favorite story about Dave,” says ASK feature writer 
W. Scott Cameron, also of Procter & Gamble, “is the 
time when he asked me to review a hierarchical presen- 
tation he was going to give." Cameron didn't think 
Stickel directly stated what he wanted from his 
audience. "My feedback," says Cameron, “was that 
he'd done an excellent job of describing a cow, but he 
should tell his audience it was a cow and not make 
them guess he had described a cow." Stickel took the 
feedback positively, and Cameron assumed that was 
the end of the story. 

A few months later when he visited Stickel’s office, 
Cameron saw a picture of a cow tacked on a bulletin 
board with the phrase “It’s a cow” under the f 
picture. “I guess Dave took my input to f 
heart," says Cameron. I 


. 
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by Dr. Kenneth L. Atkins 


I served nine years in the Air Force, and I had the good fortune to become a pilot during that 
time. I can still remember the day I got my wings. One day, I was one of the most senior student 
pilots in the Air Force and, the next day, the greenest fighter pilot that they ever saw. 


My experience as a first-time project manager on the 
Stardust mission brought those days back for me. The 
point is that one can work hard and succeed in an 
activity only to find the success is just an "entry ticket" 
to a larger, more daunting set of challenges. Confidence 
and the thrill of victory suddenly give way to anxiety 
regarding a new potential for failure. One then must 
revisit and develop a new determination to succeed at 
the next level. I’ve learned that you go through several 
steps in an adventure — the first being euphoria, second 
being anxiety, and then, finally, resolve. 

As a pre-project manager, I found myself part of a 
team — comprised of the Jet Propulsion Laboratory (JPL), 
Lockheed Martin Astronautics (LMA), and our Principal 
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Investigator from the University of Washington — 
competing against 27 other proposal teams to "win” 
selection under NASA’s 1994 Announcement of 
Opportunity for the fourth in its Discovery program 
series of low-cost, highly focused projects. Our entry was 
Stardust, a mission to fly through the dust cloud 
surrounding the nucleus of a comet called Wild 2, catch 
some of the cometary particles and bring them back to 
Earth. As a tantalizing bonus, our proposal included a 
secondary objective to capture some particles of an even 
more elusive nature. Galileo and some of our earlier 
spacecraft had discovered a particle stream going across 
the solar system, and we wanted to try to catch some of 
that stardust. We proposed to trap these smaller, speedier 


particles on our way to the comet. Hence, the name 
Stardust for the proposed project. 

Our proposal package was the subject of thorough 
discussions and reviews during an intense, competitive 
approval process. After we submitted the proposal, there 
was the usual lag time between submission, review, and 
then notification. I went back to my day job, which was 
in line management. 

Then one day I got a call from the Principal 
Investigator (PI), Dr. Don Brownlee, who said, "Hey, we 
won! We actually won this thing!" He was incredulous. I 
was stunned. I was going to manage my first project! 

Stardust had been selected from a field of 28 mission 
proposals to be part of the "Faster, Better, Cheaper" 
Discovery program series. Approval meant that we were 
locked into a $200 million contract. Not only was our 
total budget set, the funding would be delivered to the 
project based on the dollar amounts we had allocated for 
each phase of the project. 


And I thought, "Gee, this is really great! We did it! 
We succeeded!" Then, I had another thought, "But 
there’s no team.” Like me, they had all gone back to their 
day jobs. So, I had to go round all these people back up 
again — and, once I had, we were all in a wonderful state 
of euphoria. Suddenly we were walking around the 
laboratory and people were saying, "Oh, there they go. 
Those guys won. They’re the next big deal here.” 

The euphoria fades 

After we pulled the team together, we went to work on 
the project. We were all excited, saying things like, 
“We're going to bring back a thousand ten-micron size 
particles; we’re going to get pictures; we’re going to 
catch some stardust." Then we took a closer look at our 
budget as we put our work structure and our organiza- 
tion together. 

I looked at the $9.6 million budgeted for startup, 
and could see that it wouldn't be enough to get the 
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It’s one thing to put the money 
together. It’s another thing to 
put it into all the right buckets. 


project going. Eventually we would 
have all the money we needed — but 
when I looked at the schedule and 
what had to happen with our initial 
funds, anxiety set in. 

My team came to me and 
confirmed my anxiety with specifics 
on our initial dilemma. "The 
telecom radios are ‘long-lead’ items. 

To make our schedule we need to 
get on contract right away. How are 
we going to get those contracts 
funded now? We don't have the 
money budgeted in our Phase B pot 
to get started on time." And 1 
realized that we had made a big 
mistake. 

That’s when I learned that it’s one thing to put the 
money together. It's another thing to put it into all the 
right buckets, and it’s an even more crucial thing to get 
it out in a timely fashion. As we worked through the 
problem with LMA, our contractor, it was clear we had 
been overly optimistic in how much time their subcon- 
tractor, Motorola, would need to prepare a new contract 
for the transponders. We also discovered that another 
LMA project already had a contract in place for the same 
transponders we needed to buy. If we could act quickly 
we could simply "add" our units to that contract, but we 
needed about $11 to $13 million immediately. 

I met with the PI and told him, "We've got to be 
allowed to spend our transponder money earlier than we 
planned. In fact, we need to commit it now.” 

And he said, "Well, golly, you know our budget 
profile says NASA doesn’t provide that money now; they 
might not even have the cash available. Our deal was 
based on not starting the transponder contract till Phase 
C. If we ask for it now, we’re going to look..." 

"You don’t need to tell me how we’ll look,” I cut 
him off. “We may have the money budgeted for later, but 
if we can’t get it on this existing contract in Phase B 
instead of C, we’re dead!" 

So much for the euphoria of winning the 
proposal, and thinking we had everything locked up 
when our project plan was signed. We had the money, 
and we thought we knew how to do this thing — but 
our flawed cash flow plan stood between a successful 
project and us. 

Before this realization ever occurred, I had put 
together a small advisory group of Tom Gavin, flight 


systems manager on the Cassini 
mission; Tony Spear, the project 
manager on the Mars Pathfinder, 
Mike Sander, past project manager 
on SIR-C who was currently 
director of JPL’s Technology and 
Applications Program; and Joe 
Savino, a long-time "guru” of the 
electronics division. As I struggled 
to find a way out of the problem, I 
definitely needed some advice, and I 
went to them. I laid out my 
dilemma, and said, “Look, if I can't 
get Headquarters to revise my cash 
flow and give me a better funding 
profile than I've got, we won’t be 
able to do it.” 

And they said, "You know what, you're absolutely 
right.” 

"I didn't want to hear that, guys,” I told them. "I 
came here looking for a miracle.” 

Time for resolve 

I had competed with other project teams to win approval 
for my project, but it turned out that I had promised 
something that I couldn't deliver. That old cliche, "the 
Devil is in the details,” took on new clarity. If my project 
stumbled so quickly, I would essentially be putting the 
credibility of NASA's selection process in doubt. 

I decided that the best thing to do was to be upfront 
about my mistake. 1 accepted the fact that sometimes the 
only way out... is through! I was going to have to go to 
the NASA Discovery program manager and say, "I’m not 
going to spend any of your money unless I can 
guarantee we can launch this project successfully.” 1 
wasn't going to ask for any more money for the overall 
project than originally budgeted, but I needed to have 
the cash flow changed. 

So, I mustered as much of my courage as I could 
(with my tail between my legs) and set up a conference 
call with Mark Saunders, who was the Discovery 
program manager at that time. 

I said, “Mark, I've got good news and bad news. The 
good news is the project looks OK for the amount of 
money we signed up for. But the bad news is that unless 
we get some money earlier than we're scheduled for, I’ll 
have to put my badge on the table and walk away. We just 
won’t be able to make the critical path.” Along with our PI, 
Don Brownlee, and LMA program manager, Joe Vellinga, 



A technician completes work on the 
collector used to capture cometary 
particles and interstellar dust. 
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I explained the dilemma and the potential to utilize the 
existing contract to make schedule if we could fund it now. 

That's when the miracle happened. He said, "How 
much do you need?” Just those words implied hope. I 
expected something more like what a rebellious son 
might hear in a woodshed. “Are you guys nuts? You made 
this deal, now live up to it." Or worse. 

Before he had time to reconsider, I said, as casually as 
possible, "Oh, I need about eleven to thirteen million." 
(Inside I was anything but “casual," because that was a lot 
of money to have incorrectly planned in a budget profile. 
I considered it to be a big mistake, but I was desperately 
trying to keep my cool.) And he said, “Well, you're in luck. 
Our Near Earth Asteroid Rendezvous project is currently 
under-running, so my funding flexibility happens to be 
good right now. I can 'prefer' [send early] the money." 

It goes without saying that salvation does wonders 
for depression. After some appropriate-level gratitude 
statements and a little groveling-recovery, we ended the 
telecom with a new level of appreciation for careful cash 
flow planning and a resolve to not be in this situation again. 

Certainly, our admiration for the Discovery 
program manager, Mark, who had been so tough during 
the competitive phase of the proposal, skyrocketed. 
What wisdom. What mercy. He could rightly have sliced 
and diced us before giving us the money, but he chose 
to listen. He chose to understand. And with his own 
flexibility, he had achieved a higher level of motivation 
and resolve in the project leadership team by working 
with us, not on us. It was a good day. 

Stardust was successfully launched on February 7, 
1999. It has been flying extremely well, and has spent 
quite a bit of time with its collector exposed to the 
stardust mentioned early on in this story. It's on its way, 
hopefully, to a successful fly-through with the comet in 
January 2004 — and a return to earth in 2006 with both 
comet particles and stardust. I was even able to give 
money back at the end of the development and launch 
phase of the project, almost a million dollars. 

This thing about cash flow is something that I’m 
now preaching to all the proposal teams in my current 
role as a review board member. At the beginning of a 
project, cash flow is king. The reason I had this screw- 
up was because I had looked at my overall budget and 
said, "We can do this." I was inexperienced, and I didn’t 
see cash flow as an issue. 

I started this story by talking about my days of 
excitement in the Air Force. I’ll finish by talking about 
times of leisure now in my semi-retirement. I've played a 


lot of golf during my life, but I never took any lessons. So, 
frustration with my game and results has a long history. 

Just recently, I faced the fact that I had no due as to 
what I was doing wrong. I went out and hired a pro to 
help me. At the first lesson, he said, "Here’s how your 
grip needs to be." And he v/ent through a lot of other 
things, but the bottom line was, "If you don’t set up 
correctly, you can’t hit the shot.” You can imagine how 
that line struck home! 

And this is what’s key to the story' 1 just told about 
Stardust. If you don’t have that cash flow set up correctly 
along with the budget and the schedule, you can't “hit 
the shot" and you're going to be in trouble. • 

Lessons 

• Effective budget planning considers not only how 
much money a project requires, but also when the 
money is needed. 

• Many times, project success isn’t the result of not 
making mistakes; it’s the result of having the courage to 
face mistakes head on and take action. 

Question 

Does your work environment engender courage? 


^ OUTREACH 

'■* V* If all goes as planned, the Stardust spacecraft that 
4 DR. KENNETH ATKINS and his team launched in 
1999 will travel 242 million miles from Earth to 
encounter Comet Wild 2 in January 2004. En route to the 
comet, the spacecraft will collect interstellar dust particles 
believed to consist of ancient pre-solar grains and nebular. 
Stardust will capture and store these particles by extending a 
tennis racket-sized collector filled with a product called aerogel 
(a glass foam, which is the lightest solid known to man). 

Also on board: two copies each of a pair of microchips, 
engraved with over a million names — including names 
submitted by the public during a 1997-1998 outreach 
program, and all the names of soldiers memorialized on the 
Vietnam Memorial in Washington. D.C. One set of chips will 
remain on the spacecraft as it goes on to orbit the sun. The 
second set will return to earth along with the aerogel collector 
in January 2006. aboard a 125-pound reentry capsule. 

The story by Atkins was based on his presentation 
at the February 03 APPL Masters Forum. Atkins can be 
contacted at Kenneth.LAtkins@jpl.nasa.gov. Visit the Stardust 
Web site at http://stardust.jpl.nasa.gov 
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build A project A hundred times in my week before the job was finished, and then install them, 
head before we start work on it. I put formal plans into Great idea, everyone agreed. It would require a little 

writing, but I also try to work through every scenario I more money for shipping, but that was acceptable, 

can think of in advance to have everything lined up like With a week to go, I believed that the job was going 

dominoes, with all the details in place. well — until I got a phone call from the superintendent. 

But things still go wrong — like the time we had "The doors are here, the frames are here, all 25 of 

twelve weeks to demolish one floor of a building, then them, and they look great, ' he told me. But then he 

build it back. After reviewing the client's drawings, 1 told added the line made famous in the Apollo 13 movie: 

them that the twelve-week schedule wasn't going to "Houston, we’ve got a problem." 
work the way they had things sketched out. "What’s the problem?” I asked. 

“You have us finishing the frames after the drywall’s "The frames don't fit in the freight elevator." 

in," I pointed out to them. “But the doorframes are clear "Then carry them up," I told him. "You know, get 

oak, and there’s not enough time." I outlined the man- some guys and haul them up the stairs." 
hours and the timing required to do the job the way they “We’ve already tried that. They won’t make the first 

had stipulated, and explained why it couldn’t be completed turn because of the jog and the — ” 
on schedule. Then I offered an alternative solution. "I’ll be right there,” I told him. 

Instead of waiting to build the frames on site, I It was at that point that I got that feeling in the pit 

suggested having them built in advance at a Canadian of my stomach that every manager gets when a 

millwork factory. We could have them shipped down the problem crops up with about a week to go on a project. 


I got that feeling in the pit of my stomach that every manager gets 
when a problem crops up with about a week to go on a project. 
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It’s about the time you start thinking, “Maybe I should 
just keep driving.” 

How was I going to get these oversized frames up to 
the 1 2th story of a building and installed in a week for 
one of our best clients? This was a client worth millions 
to my company. I couldn't ask them for more time; they 
had already scheduled the movers and the utility instal- 
lations. Everything had to happen that weekend. I still 
needed to file inspections before the client could move 
in, and 1 couldn't schedule the inspections until we had 
the doors on and working properly. 

As 1 was driving to the site, I started thinking of new 
approaches to the problem. The superintendent had 
told me that the frames couldn’t make the first turn. But 
could they make the second? I called back and asked. 

“What difference does it make if they fit through 
the second turn?’’ he asked me. "We can’t get them past 
the first turn." But I was already thinking: Let’s figure 
out a way to get rid of the first turn. 

In the meanwhile, I arrived at the site. As I parked, I 
looked at what was next to me: another one of my 
company's projects. We were constructing a building right 
next door, and we had a tower crane sitting on the site. So 
I asked the superintendent, “How about if we carry the 
frames down to the 12th floor from the roof?" And he 
answered, "We didn’t think about that. But the frames 
aren’t on the roof; we have them on the loading dock.” 

I went over and spoke to the superintendent on the 
other job. In a matter of minutes we had the frames lifted 
to the roof with the crane. Then all we had to do was to 
carry them down two flights, instead of up twelve. 

It all worked out, and our customer never knew 
there was a problem. As far as the client was concerned, 
the job was completed on schedule and the doors 
looked great. But we knew that disaster had been 
narrowly averted. Back when we were planning the job, 
all I had needed to say was, “How are we going to deliver 
these pre-built frames to their locations? Let’s check the 
freight elevator.” Just one more detail, and we would 
have had everything running smoothly. 

I've learned that whenever I come up with a unique 
solution to a problem, I need to be prepared to consider 
the implications of applying that solution. What 
elements of my plan are affected by the solution? What 
elements of the project need to be adjusted based on 
these changes? 

But if it were only that simple... the truth is that 
while we can avoid some problems by asking the right 
questions, there still will be problems to be solved and 


lessons to be learned on every project. Recognizing this 
helps me to be mentally prepared to meet the challenges 
in front of me, armed with two essential tools: experi- 
ence and flexibility. 

I try to remember what I learn on projects and carry 
those lessons forward. Now, for example, I give every 
contractor on every job the dimension of the freight 
elevator with the pricing proposal. With that, I no longer 
own the problem. It’s the contractor's responsibility to 
build something we can fit in the elevator. 

Just as importantly, when problems do pop up, I try 
to stay open-minded about potential solutions, and put 
creative thinking to use. I try to remember that what 
doesn't go up, might just come down. • 

Lessons 

• Even experienced project managers can’t anticipate 
every potential problem. Part of planning ahead should 
include allowing oneself the flexibility to rethink the 
plan and improvise if necessary. 

• Unique solutions to problems sometimes create a set 
of new problems unique in nature as well. In dealing 
with sudden changes in planning, try to consider what 
other elements of the project will be affected, but don’t 
second guess yourself into a state of inaction because 
you can’t anticipate every contingency. 

Question 

How do you create a culture that fosters both detailed planning 
and flexibility? 


On almost every day of the 
<gyJB year, HITT Corporate Interiors 
begins work on about twenty 
llfw* &&?. commercia l construction projects 
and completes another twenty. 
As a senior project manager for HITT, 
CHRISTIAN ZAZZAU has multiple project 
managers reporting to him at any given time. His 
job: to keep all the plates spinning. 


Zazzali has been with HITT since 1999. He has 
received the Associated Builders & Contractors' 
Excellence in Construction Award. Zazzali's story 
"Thanksgiving Hocus Pocus" appeared in ASK 10. 
He can be reached at czazzali@hitt-gc.com. 
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"SEDUCTIVE" IS A WORD RARELY ASSOCIATED WITH PROJECT MANAGEMENT. AN 
EXPRESSION LIKE "24/7," ON THE OTHER HAND, IS ALL TOO FAMILIAR. MARRY THESE 
TWO, AND ANOTHER WORD IS BORN: "E-MAIL." 


Since e-mail generates itself on a round-the-clock, 
daily basis, it’s not unusual for me to receive an average 
of fifty e-mails a day, or more than 300 a week. That's a 
lot of e-mail. 

1 have spoken with many of my fellow project 
managers about my relationship with e-mail. In my case, 
reading and responding to it is a temptation almost too 
hard to resist. When I receive an e-mail 1 tend to want to 
stop everything I'm doing, and open and answer it. 
Indeed, in my life you could say e-mail is a force to be 
reckoned with. 

Interestingly, my fascination with mail began a long 
time ago. I trace it back to my days as a young boy when 
I started receiving my first letters from friends and 
family. Walking home from school, I was often filled with 
curiosity, wondering if I had received any mail that day. 
In college, I knew the exact time the mail was delivered, 
and 1 headed for my mailbox as close to that hour as I 
could. After that, I served in an Army Reserve Post Office 
Unit, where I came to realize how important a postal 
unit was to the military. There were many others like 
myself, far from home, who relied on the written word to 
stay connected to the people in their lives. 

Over the years I have changed in many ways, and so 
has the mail. But the same sense of connection, and the 
same urge to respond to someone who has written me, 
remains. The 24/7 nature of e-mail has compounded the 
situation. It is relentless in its pursuit of my time and 
attention — and, as such, e-mail has become something I 
have had to manage in a variety of situations. 

I've learned that being seduced by e-mail is far from 
uncommon experience. I was talking with another 
manager and he told me he was having problems with 
some of his younger engineers, as they were spending 
more time on their computers answering e-mails than 
on the shop floor managing their projects. He wanted 
the engineers to interact more with the people on the 
shop floor, and he felt this problem was having a 
negative impact on their performance and how their co- 
workers perceived them. When he confronted one of the 
engineers, the response he received was that it was the 
engineer’s job to answer e-mails — not necessarily to be 
on the shop floor all the time. They both had a point. 

Project managers must lead by example. As we 
continue to increase the amount of time we spend on 


tasks like e-mail, so must we continue to improve our 
time management skills. We need to make conscious 
decisions about the minutes and hours we will spend 
staring at the screen and emptying the inbox, and how 
we will utilize this tool to our advantage. 

/ 

What worked for snail mail, works for e-mail: 

Back when snail mail was the only mail 1 had to 

contend with, a performance coach taught me a 

few tips that I continue to use today. 

• Touch each piece of mail only once. 

• Either pitch the mail or respond immediately. 

(As a last resort, defer action until another day.) 

• Keep a minimal number of files so you’re not 
tempted to warehouse a large amount of mail. 

Another situation I've had to deal with is whether to 
take my computer on vacation or leave it at the office. 
After much thought and negotiation with my family, I 
decided to take my computer on vacation. I have received 
many comments about this decision (i.e. are you a 
workaholic, are you crazy, a vacation is for rest not 
answering e-mail). I really can’t argue with these 
comments, but 1 have imposed some restrictions on 
myself so my vacation isn't just an alternative work 
location: I don’t read my e-mail every day of vacation, I 
don’t let what I read in an e-mail change the timing of 
any of our vacation plans, and I only access my e-mail 
during "dead time” when my family is doing other things. 

I've reasoned taking my computer on vacation is 
healthy for me. It reduces my stress level upon return to 
work. While it’s still easy for me to get excited about a 
letter waiting in my mailbox, coming home to 350 or 
more e-mails is hardly what I would call “seductive.” • 

t 

W. SCOTT CAMERON is the Capital 
Systems Manager for the Food & Beverage 
Global Business Unit of Procter & 
Gamble. He is also a regular contributor 
to ASK Magazine. He can be reached at 
cameron.ws@pg.com. 
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REQUIREMENTS 


THE MORE THE BETTER? 

BY TERRY LITTLE 


26 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP 





For as long as I can remember, we in the Department 
of Defense have based our development programs on 
user requirements. The process is more or less sequential. 
The user develops the requirements, supposedly driven 
by the threat, and the developer structures a program to 
satisfy them. 

Great process, right? Nope. It’s a bankrupt process 
that has failed time after time. 

In truth, most of the so-called "requirements" 
are really "desirements." 

They have little or 
nothing to do with the 
threat or real need, 
but everything to do 
with what the user or 
sponsor thinks may be 
possible. And what’s the 
worst part? Much of 
what ends up in the 
requirements stem from 
what overly optimistic, 
fiscally naive program 
people — government or 
contractor — eager to "sell” the program have told the user 
or sponsor they can do. 

When the chickens come home to roost, as they always 
do, one can invariably trace many a program problem 
to having written unrealistic expectations into the require- 
ments. It’s a self-fulfilling prophecy. 

How does one deal with this? Simple. Nothing ever, 
ever, becomes a requirement until two things happen: (1) 
there is a solid understanding and acceptance of the 
requirement's cost and schedule implications; and (2) 
knowledgeable technical people are so confident that the 
program can meet the requirement within the cost and 
schedule that they are willing to bet their jobs on it. 

Yikesl! Does this mean that we never undertake 
high-risk projects? No. What it does mean is that when 
you undertake high-risk activities, you agree on an expec- 
tation or requirement that includes failure, or falling 
short, as a real possibility, and your cost and schedule 
reflect the risk. The other thing that it means is that you 
may have to start a project with some requirements open 
until after the work progresses to a point where the 
requirement meets the two criteria above. 

The process is also flawed because there are usually 
too many requirements. Something about the 
engineering or designer mentality seems to demand hosts 
of requirements as an input to the technical process. 


Granted, it’s more comforting to have someone else issue 
the requirements than it is to have to derive them. But, 
being overly constrained by too many requirements with 
too little wiggle-room will invariably create problems. In a 
perfect world, a sponsor’s requirement would only be to 
obtain a certain capability with the detailed technical 
requirements derived from what's truly possible. 

Linked to this issue of over-specification is the 
problem of prioritization of requirements. If everything is 

equally important, then 
nothing is important. 
In my estimation, a 
program or project 
should start with only a 
few key requirements. 
"Few" means not more 
than four or five, and 
"key" means that, if the 
program doesn't meet 
these requirements, it 
should be terminated. 

Finally, within DoD 
cost is almost never a 
requirement, much less a key requirement, but it should 
be — always. Cost is a technical issue. We can only buy 
as much technical requirement as we can afford. It’s 
true when we buy a car, and it’s also true when we initiate 
a project. 

My practice has been to put cost — which may be 
development, production, or both, depending on the 
program — into the technical performance specification. 
Why do this? I do it to make clear that everyone on the 
project, most especially the technical people, must own 
cost just as they do performance. Cost can't be just the 
concern of the project manager or the budget analyst. 
Everyone has to own it. 

So what does all this mean? Simple. One sows the 
seeds of a project's success or failure during the 
requirements stage. With bad seeds the fruit will be 
bitter indeed. • 


TERRY LITTLE is the Director of 
the Kinetic Energy Boost Office at the 
Missile Defense Agency. One of the 
most seasoned program managers in 
DoD, he is also a regular contributor 
to ASK Magazine. 


Being overly constrained by 
too many requirements with 
too little wiggle-room will 
invariably create problems. 
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AS AN ACTIVIST FOR THE PROJECT COMMUNITY AT NASA’S 
Ames Research Center, I see my role as finding out what 
resources project managers need to help them run 
successful projects. I need to go out and advocate for 
those resources, if necessary, and I need to be 
supportive — not just for the projects, but also for the 
project managers and their teams. It’s not something I 
can do sitting at my desk waiting for the phone to ring. 

To me, that’s what an activist does. It’s public service. In 
this case, my public is the project-practitioner community. 

From the streets of Palo Alto to the stars 

When I first came to California in 1972, 1 went to work 
at a drug abuse treatment center, right in the middle of a 
Palo Alto business community — a community who. 


incidentally, circulated petitions in an attempt to prevent 
us from moving in. They didn't want drug addicts living 
in the neighborhood or hanging around their businesses. 
At the time, the only place people detoxified was in the 
street or in jail. Or they died. 

Within two years, the very same business people 
who got the petitions signed to have us barred were 
getting petitions signed for the city to continue our 
funding in the same location. 

How was that? 

It was about building relationships. For example, 
the leader of the we-don't-want-those-folks-in-here 
movement was a barber whose shop was right next door 
to our drug treatment center. A few of us from the center 
would talk with him over a game of chess because we 
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learned he liked to play. He got to know us. Then we 
started going out to lunch with him. Eventually, we 
brought clients to his shop for haircuts. Little by little, he 
became a part of the community that we were serving, and 
an advocate. And this all happened before the night his 
son overdosed. That night, we were the people he came 
to, the people who saved his son’s life. 

We were building a community — -just like we're doing 
now at Ames, and with the Academy of Program and 
Project Leadership (APPL). This time around, we’re trying 
to build a community of practice. We’re trying to spread 
the message that knowledge sharing isn't something that 
you do to people. It is something you do with people. 

APPL West 

When I came to Ames in August of 1998 in the 
Training and Development Group, I was the fifth 
person in that job in two years. People were skeptical 
that I would be any more successful than my predeces- 
sors, but a part of my approach is that I don't carry 
around other people's legacies. After all, if I didn't 
believe in people's capacity to do wonderful things, I 
never would have been a drug treatment counselor. I 
would have been a drug dealer. 

One of the items on my to-do list was to learn if 
anybody was interested in project management 
training. I didn’t come in with an agenda. My approach 
was: What do you want? What do you need? How can 
I help you? 

I didn't know anybody. The fact that I was in a 
position of having to ask questions helped me connect 
with people at Ames. For example, as 1 talked to people, 


turned Ames into APPL West and brought APPL 
resources to the West Coast?” 

He said, "Oh, oh, okay, sure.” Later, as Ed tells it, he 
turned to Tony Maturo, APPL Deputy Director, and 
said, "Who is this nut case from California?” 

The only catch was that I had to make it happen. 
But it was even more complicated than that. As I quickly 



Ames Research Center wind tunnel facilities at Moffett Field, California. 


discovered, a constellation of forces needed to be 
brought together to say, "We are going to make this 
happen." For example, my organization managed the 
training conference center building. Lodging, however, 
was managed by another organization. Then there were 
the procurement people, whose buy-in was needed in 
order to release Ames training dollars to do these 
residential courses. So I had to convince a lot of different 
people that this was good for the project management 
community and good for Ames, in terms of bringing 
courses here that people wanted. 


not something I can do sitting 


at my desk waiting for the phone to 


ring 


I found out that the number one reason why people 
weren't going to training was the lack of travel dollars. 
There were other issues, of course, but that was one I 
thought I could handle. I said, "Well, if we can't go to 
Wallops Island, Virginia [where APPL conducted all of 
its project management training courses], then we will 
bring APPL to Ames.” 

The very first time 1 met with Ed Hoffman, the 
APPL Director, I said, "Ed, what do you think if we 


The first thing I did was to take a community-organ- 
izing approach. Rather than simply throw it together and 
say, "This is a Claire thing,” I wanted it to be something 
that was independent of me, something that would 
continue because it existed as part of the culture, rather 
than because one person wanted it to happen. I invited 
other people to join me in planning our first steps. 

We started off with one class. We made up flyers. 
We had leaflets. I passed them around like 1 did in the 
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old days. I put them on people’s windshields. I handed 
them out as people walked in the cafeteria. 1 did a 
mailing. The class filled. 

Ed Hoffman came out for the class — probably to see if 
the "nut case" could pull it off. While he was here, 1 decided 
to have a community meeting to introduce APPL. I hoped 
to pose a question to my fledgling community, "What can 


"It will never happen," people told me. That gets back to 
the message I received when 1 first arrived at Ames: 
Nobody cares. Nobody is interested. Nobody will come. 
It will never work. 

But I decided, as always, that I would try it anyway. 
And, you know what — people came. There was clearly 
an appetite, and it was obvious from the energy on 


We're trying to spread the message that knowledge sharing isn't someth, ng that 
you do to people. It is something you do Wltn people. 


we do here at Ames to really look at and pay attention to 
project managers, and project management development 
and training?" That would be the first time we asked this 
question in a public forum, but not the last. In fact, it is a 
question we ask continuously. Asking it is part of how we 
are building a community of practice here at Arnes. 

During the planning meeting for the APPL 
community meeting, 1 was told that no one would come. 


display at that meeting that people wanted the opportu- 
nity to come together as a community. 

That APPL West community meeting was just the 
beginning of a project that continues on today. I still see 
myself as an activist. I still think there's so much more 
we could be doing. But here’s the happy ending to my 
story: I'm not alone. • 



At The Tipping Point 

“A lot of folks don't even know the project leaders who work in the same building, let alone 
in the same code, let alone in the same center, let alone in the same agency,” says CLAIRE SMITH, 
commenting on the conditions that led to the burgeoning Knowledge Sharing Initiative (KSI) 
she has organized at the NASA Ames Research Center. Since coming to Ames five years ago, 
Smith has worked to nurture a community of practice among the Center's project managers. 

Today, her KSI mailing list goes out to almost 1,500 practitioners. In addition to distributing 
ASK Magazine and hosting guest speakers (including Stanford professor Robert Sutton, author 
of Weird Ideas That Work), Smith has planned and promoted scores of events designed to bring 
the project management community together. “We’ve had pizza parties. We've gotten together 
for dinner," says Smith. “Anything that brings people together to tell stories that share experi- 
ences and ideas has the effect of building a community." 

Cartoon drawing provided by Claire Smith’s old friend Joan Baez. 


For more information about knowledge sharing at Ames, contact Claire Smith at csmith@mail.arc.nasa.gov 
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During his nisn.\'c;tT.siii:n 37-ykar cari i r at NASA, 
Madden synthesized in-the-trenehes experience into his 
"100 Lessons Learned for Project Managers." 

„ Eventually, the list grew to include 128 lessons, but the 
name never changed, and the collection of mostly 
serious, sometimes funny observations about project 
management remains widely recognized — and often 
quoted — inside and outside the Agency. 

Among the wisdom captured in Madden's lessons, were 
words of warning. Madden identified both the common 
pitfalls of project life and the best wavs to avoid taking 
the plunge. Never one to shv away from difficult 
subjects, Madden's lessons talk frankly about project 
management's “f" word: failure. Here we excerpt fifteen 
of Madden’s lessons that deal with project challenges. 


[#90] The seeds of problems are laid down early.... 
Review of most failed projects or of project problems 
indicates that the disasters were well planned to happen 
from the start. 

|# 122] loo much cost data on a proposal can blind you 
to the real risks or forgotten items. 

]#126| Make sure everyone knows what the require- 
ments are and understands them. Much easier to sav 
than do.... "You have to have the right people look at 
requirements. A bunch of managers and salesmen 
nodding agreement to requirements should not make 
vou feel safe. 
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[#3] The source of most problems is people but damned 
if they will admit it. Know the people working on your 
project, so you know what the real weak spots are. 


[#97j Talk is not cheap. The best way to understand a 
personnel or technical problem is to talk to the right 
people. Lack of talk at the right levels is deadly. 


[#20] Managers who rely on the paperwork to do the 
reporting of activities are known failures. 

[#91] A comfortable project manager is one waiting for 
his next assignment or one on the verge of failure. 
Security is not normal to project management. 

[#110] Though most of us in our youth have heard the 
poem that states “for want of a nail the race was lost,” 
few of us realize that most space failures have a similar 
origin. It is the commonplace itein.s that tend to be 
overlooked and thus dew us in. The tough and difficult 
tasks are normally done well. The simple and easy tasks 
seem to be the ones done sloppily. 


[#44-] Mistakes are all right, but failure is not. Failure is 
just a mistake you can't recover from; therefore, try to 
create contingency plans and alternate approaches for 
the items of plans that have high risk. 

[#54] All problems are solvable in time, so make sure 
you have enough schedule contingency — if you don't, 
the next project manager that takes your place will. 

[#31] Redundancy in hardware can be a fiction. We are 
adept at building things to be identical so that if ene 
fails, the other will also fail. Make sure all hardware is 
treated in a build as if it were one of a kind and needed 
for mission success. 

[#78] History is prologue. There has not been a project 
yet that has not had a parts problem despite all the 
qualification and testing done on parts. Time and being 
prepared to react are the only safeguards. 


[#32] Don't be afraid to.fail or you will not succeed, but 
always work at your skill to recover. Part of that skill is 
knowing who can help. 


[#22] If you have a problem that requires the addit ion of 
people to solve, you should approach recruiting people 
like a cook who has under-salted, i.e., a little at a time. 

[#29] In case of a failure; 

a. make a timeline of events and include everything 
that is known; 

b. put down known facts — check every theory 
against them; 

c. don't beat the data until it confesses, i.e., know 
when to stop trying to force : fit a scenario; 

d. do not arrive at a conclusion too rapidly. Make 
sure any deviation from the norm is explained — 
remember the wrong conclusion is prologue to 

* the next failure; 

e. know when to stop. 


LESSONS FROM THE MASTER 

Les Meredith, former Director of 
Space Sciences, had this to say of 
JERRY MADDEN and his project 
do's-and-don'ts: “God only gave us 
Ten Commandments. Jerry has 
listed over a hundred instructions for a Project 
Manager. It is evident a lot more is expected from a 
Project Manager." 

Madden retired from NASA in 1995 as Associate 
Director of Right Projects at Goddard Space Right 
Center. Considered by many of his peers to be one of 
NASA's premiere project managers, Madden’s reputa- 
tion for frank, on-target observations of project 
management continues to be celebrated today, as his 
list of lessons is handed down to a new generation of 
project managers. 

Naturally, not all of Madden’s wisdom made it into his 

"100 Lessons." Marty Davis, who worked under 

Madden at Goddard, recalls one of the unwritten 

lessons: “Show up early for all meetings; they may be 

serving doughnuts." 

< 

Jerry Madden can be reached at maddenjeremiah 
@netscape.net. 
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Donald Margolies 


Since 1963 , Donald Margolies has served in a number of management positions 
at the NASA Goddard Space Flight Center, and in 1998 received NASA's 
Outstanding Leadership Medal 


Margolies received the award in recognition for his 
innovative leadership of the highly successful Advanced 
Composition Explorer (ACE) mission. ACE launched in 
August 1997, and has been providing scientists with 
information about space matter and near-real-time 
advance warning of geomagnetic storms. ACE is one of 
several missions run in the NASA Explorer Program, 
which is characterized by relatively low to moderate cost 
and small- to medium-sized satellites capable of being 
built, tested, and launched in a short time. 

Most recently, he served as observatory manager on 
another Explorer Program mission, the Microwave 
Anisotropy Probe. Prior positions at Goddard include 
project manager for the Total Ozone Mapping 
Spectrometer mission, deputy project manager for the 
Explorers and Attached Payloads Project, observatory 
manager for the Solar Optical Telescope Project, obser- 
vatory manager for the Active Magnetospheric Particle 
Tracer Explorers Project, and spacecraft manager for the 
Magnetic Field Satellite. 

As he approaches retirement, Margolies has been 
active in the APPL Knowledge Sharing Initiative, 
including serving as a member of the ASK Review Board. 
His other awards include NASA’s Exceptional Service 
Medal and the Goddard Space Flight Center 
Outstanding Service Award. 


You wrote a story about your work on the Advanced 
Composition Explorer (ACE) project for ASK (Issue 9). I 
remember that you said that your “ primary objective was 
to launch on schedule. ’’ How do you get a project team to 
make that happen? 

I have approached it in a number of ways. For example, on 
one project I have gone so far as to take my team away from 
our normal business site for a week. Everybody sat down 
and developed their schedules, and then using such high 
tech tools as pencils, paper, and rulers, we put together a 
networking diagram. People could look at that and say, "No, 
no, this isn't right, we need to do this first." That was one 
way I got people together to agree on a schedule. 

On some projects, schedule slips have been blamed on 
tension between the science team and the project manage- 
ment team. Did you do anything specific to try to mitigate 
that sort of tension on ACE? 

I worked closely with both the principal investigator, 
Dr. Edward Stone, and the payload manager, Allan 
Frandsen. My relationship with A1 took on much greater 
significance as the project evolved, because fairly early 
on Dr. Stone also became the director of the Jet 
Propulsion Laboratoiy. At any one time, there were 
always several things competing for his time and 
attention. Still, we communicated regularly. 
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Did you two have some kind of system set up for that? 

Only in that we made it a practice not to ignore commu- 
nication. Dr. Stone and I set up a schedule to talk with 
each other on the phone every week. Even if it was to say 
that the weather was nice in California and there was 
nothing much happening here at Goddard, we always 
kept the appointment. 

What are some of the common pi falls you've seen on 
projects in terms of how scheduling is treated? 

Well, I’ll give you an example. On one project, I went to 
visit my contractor, and 1 met with their scheduler and 
project manager. We went into their war room, and there 
were schedules all over the wall. They were wonderful, as 


be done. As a project manager, there are certain things 
you can dictate: the end date, maybe certain review 
period dates; but in terms of what else has to be done, 
you’ve got to ask the people who are doing the job. 

So you felt that schedules they had shown you had no 
basis in reality? 

None. Here were these wonderful schedules, detailing 
every single thing you ever wanted to know about the 
project — and it was totally irrelevant. Now, understand, 
I am not against using schedulers. 1 have worked with 
several good ones. But you need to talk to the people 
doing the work. You need to find out what they have to 
do and how long it’s going to take. Even if you do it that 


THese fsowoeaFUL, schlouces , tA/l/a/l bveyy 

TH/flJG yoi/ Z YE /? WA/YTeO Te /CA /oi«/ about THtT F/ZoTCCT- 
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detailed as can be, and so I had to ask: "Who developed 
the schedule?" The scheduler said, "I did." And so I 
asked another question, "Did the people doing the work 
have input?" He said, "No." 

The next day I notified the contractor that I wanted 
the project manager and his scheduler removed from 
the project, and 1 told him to start building schedules 
that were representative of what work really needed to 


way, your schedules can still be fallible, but at least you 
have something that everybody has bought into 
because they helped to develop it. 

Were there any unique scheduling challenges you 
faced on ACE? 

The scheduling challenge on ACE was working with 
twenty science institutions. It was a big team, spread out 
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widely across the U.S. and parts of Europe. They were all 
experts in their own scientific and technical domains, 
but creating and adhering to schedules wasn't their forte. 
So the real challenge was making sure all of the 
schedules converged on the same launch date. 

In what way, for example by looking at a decision you 
made at some stage of the project, were you able to 
address that challenge? 

At the start of the project, I had the choice of spreading the 
limited amount of money I had among all the players, or 
looking at and mitigating the greatest risks on the project. 

1 responded by putting the bulk of the money into 
trying to identify the key risks in the development of the 
science instruments and mitigating these to the best 
extent that we could. I wanted to enter the development 


stages of the project, the question was: What was the 
best way to use it? 

How did things turn out? 

Once we got more funding, I told APL to start ramping 
up on the spacecraft development. As it turned out, they 
were able to catch up. 

You’re never right a hundred percent of the time. 
Still, you have to go with your judgment. Experience 
counts for a lot. 

At one of APPL's Masters Forums, you told a story about 
how you worked with Mary Chiu to address a schedule 
concern you had about APL. What struck me about that 
was you said you learned something about people's 
motivations on projects. 


You're /YEV£tZ jC/OMT A HvNDfiZb AErzeerJT 0F T/*)E. 
STILL , You HAUL TO Go kJ/TH JuOGE T)EA/T. £X AeiZlEfUCE 

GOOa/TS Eo/z. A LOT. 


phase with the least amount of technical, schedule, and 
cost risk as possible. To do this, 1 had to limit spacecraft 
development funding at the Johns Hopkins Applied 
Physics Laboratory (APL). 

What were the risks involved in doing this? 

In holding APL back by three months, or six months, 
I knew I could be shooting myself in the foot if they were 
not able to recover. But I believed, even with a slow start, 
APL would be able to catch up. 

Why? This was my third mission with APL, and I 
thought I understood the culture there. Mary Chiu, the 
APL Program Manger, was new to me, but I knew many 
of the other key people on the project. APL had built 
spacecraft many, many times before. My concerns about 
APL being able to do the job actually were quite minimal. 

On the other hand, no one was certain how effec- 
tively we could mitigate the risks with those problem 
instruments. The greatest uncertainty on a science 
mission is in the development of the instruments. There 
were nine on ACE, five of which were new. Because I was 
limited as to how much money I could get in the early 


Yes, I remember. The story was that APL had fallen 
behind schedule as we were approaching our integration 
and test phase. We not only had to integrate the space- 
craft and test it, we had the nine instruments coming in. 
It looked to me like there was only one of two ways to 
make up the difference: either put some people on 
double shifts, or work on the weekends. Neither was an 
attractive alternative, but we had a lot to do and the work 
had to get done. 

I asked Mary to go ahead and tell her people to do one 
or the other. She told me that she couldn’t do that. Her 
people were salaried and she couldn't direct them to put in 
overtime, where they wouldn’t be paid for their work. I 
have to admit that took me aback. For one thing, I wasn't 
asking for a lot of time — perhaps seven days at most. 

But I have to give Mary credit. She pointed out 
something that was a no-brainer, really. Technically, she 
couldn't require her people to work the extra hours, but 
she also knew that she didn't have to tell them to do 
anything. Professionals don't have to be reminded that 
they have a job to do. It was so obvious that I was aston- 
ished and embarrassed that I hadn’t realized it myself. 
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These were people atAPL that you'd worked with before? 
Yes, that's true. I knew a number of people on the APL 
team because I'd worked with them before, and I recog- 
nized that what she was saying was true. These people 
would come in and work the extra hours; they would 
work Saturdays, Sundays, nighttime, whatever it took to 
do the job. All we had to do was put it out there that we 
were behind schedule, and they would rise to the 
challenge on their own. And they did. Ultimately they 
recovered all of the time. 

So what was the important piece of learning about 
people's motivations on projects? 

Well, it is much better to let people come up with a 
solution and implement it than for you to force it down 
their throats. Isn't that preferable to mandating that 
they do the work? Think about it from APL’s stand- 
point, if they heard NASA telling them to work harder 
than they already were — with NASA knowing full well 
these people weren't going to get paid for this — it would 
be like NASA was trying to get something out of them 
for nothing. 

The mission launched, and it has been very successful in 
terms of the science collected. But are you satisfied in how 
you met the challenges you identified? 

Let me put it this way, we picked a target launch date 
three and a half years in advance of launch, and if there 
had not been a launch vehicle problem on a different 
mission we would have launched on that day. As it was, 
we launched four days late. 

That's incredible when you think about how common 
launch slips are. Six months, or a year is hardly unprece- 
dented. So are there any rules of thumb that you would 
encourage project managers to follow when building 
schedules? 

Just this. There is this tendency to think there’s only one 
way to get from A to B. It turns out there are an infinite 
number of ways to get from point A to point B. What 
may work on one project may not work very well on 
another project for a variety of reasons. 

The lesson I've learned is that while it's good to 
have a road map, you have to realize the map is good for 
today, but it may change tomorrow, and it may change 
again the next day. Use the schedule as a tool and be 
flexible, if you can. Cultivate a great team, take advantage 
of their experience, and pray for good luck. ® 



from the editor-in-chief Dr Alexander Laufer 


Management as Improvisation 


Things are supposed to work a certain way — 
and then there's what really happens 


Despite the best planning, gaps emerge between the 
model and the reality of most projects. Often, when 
unexpected problems arise during project implementation, 
quick thinking and a pragmatic approach are the tools 
managers need to bridge the gap. 

I was reminded of this when I spoke with a project 
manager in charge of modernizing old buildings for the 
Federal Government. Though he had straightforward 
goals (removing asbestos, updating wiring, etc.), achieving 
these goals proved anything but straightforward. The 
real challenge, the manager discovered, was completing 
his work without disturbing the tenants still occupying 
a building. 

QUIET ZONE At one of his sites, a Federal courthouse, 
workers had continually violated noise restrictions 
imposed during the hours that court was in session. 
Typically, when noise complaints came in, someone 
from the project office found the source of the problem 
and reminded workers of the restrictions. When 
confronted, workers explained that they either hadn't 
known about the restrictions or had forgotten them. 

The solution? Directly addressing those who could 
control the noise — the workers — and making it clear that 
they would be held responsible for their actions. The 
project manager posted the noise restrictions at every 
construction entrance — along with a warning that 
violation of noise controls could "result in immediate and 
permanent removal from the job site.” A simple sign was 
all it took to address a significant threat to project success. 

LIVE WIRES On another project, demolition work on 
one floor of a building disrupted the telecommunication 
service to occupied offices. It turned out that years of 
office space reconfigurations had resulted in tangled 


wiring that wound its way between floors and through 
offices. For example, stripping a telephone closet on the 
12th floor cut service to offices on the 14th floor. 

The obvious solution was to hire a technician to 
systematically trace all the wires and eliminate the 
problem upfront — but the project couldn’t afford this. 
Instead, the manager found a retired technician willing to 
work "on call" to identify live communication lines before 
renovation began in an area, using a listening device. This 
low-cost solution provided a satisfactory solution. 

A NOSE FOR TROUBLE When the roof of a fully 
occupied office building needed to be re-tarred, 
occupants complained that the noxious fumes were 
reaching their offices. The project manager learned that 
fresh-air intakes on the roof were sucking in the fumes 
whenever the wind blew in their direction. The air 
intakes couldn't be turned off completely, if the building 
was to remain occupied. 

The building manager threatened to evacuate all 
5,000 occupants, which would bring the project to a 
standstill. When experts couldn't come up with a 
technical solution, the project manager came up with an 
innovative fix: He invented a new occupation. He hired a 
"sniffer” to sit beside the intakes and sniff the air for tar 
fumes. When the wind blew fumes towards the intakes, 
the sniffer turned them off temporarily — never for more 
than a couple hours, and well within acceptable limits. 

KEEP IT SIMPLE As this manager learned, the 
unknowns of project work often require immediate 
response. Thankfully, high-performance results don't 
necessarily require high-tech solutions. Quick, simple, 
and inexpensive fixes are sometimes the answer to 
keeping a project on schedule and within budget. • 
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CAREER DEVELOPMENT 
PERFORMANCE ENHANCEMENT 

KNOWLEDGE SHARING 


NASA's Academy of Program and Project Leadership 
provides for project practitioners to excel. APPL supports 
individual practitioners, teams, and NASA projects and 
programs at ever)' level of development by providing 
services that manage risk, maximize human capital, 
contain cost, maintain project schedules, develop high- 
performance teams, and promote mission success. 
Academy services help the NASA project community 
meet today's missions and prepare for tomorrow’s 
challenges, in advance of need. 

Blended Learning Process 

APPL's three business lines-Career Development, 
Performance Enhancement, and Knowledge Sharing-all 
provide essential project management competencies. 
Practitioners choose the blend of courses, direct onsite 
project enhancement, or knowledge-sharing activities 
that best suits their career and project needs. 
Practitioners interested in an APPL service for themselves 



or for their organization can find contact information on 
the Academy's Web site, www.appl.nasa.gov. 

Career Development programs help individuals to 
accelerate project leadership maturity. The Academy 
provides a framework, the Project Management 
Development Process, which identifies key project man- 
agement competencies, and it offers a curriculum 
designed around these competencies. In addition, the 
Accelerated Learning Option offers a unique learning 
opportunity to mid-career project managers. 

Performance Enhancement services connect world- 
class subject matter experts with project teams. APPL 
providers deliver innovative assessment tools, 
workshops, simulations, and other materials to the NASA 
project community. Tailored support enhances a 
project's probability of success by delivering the right 
services to a project team in any stage of development, 
from project start-up through close-out. 

Knowledge Sharing products and activities facilitate 
communication and the transfer of knowledge between 
project practitioners. Through forums, workshops and 
ASK Magazine, the Academy shares project management 
best practices and lessons learned across the Agency- 
capitalizing on the experience of mature managers and 
supporting the "One NASA" vision. 

The Academy also creates opportunities for project 
management collaboration through research and 
exchange with universities, other government agencies, 
professional associations, and industry partners. Based 
on this research, APPL continually refines its services to 
ensure that its programs reflect the latest developments 
in the industry, the Agency, and the Nation. 


To learn more about APPL services and programs, 
find contact information at www.appl.nasa.gov. 




KNOWLEDGE SHARING 


NASA’S GREATEST ASSET is its human capital. The Academy of Program and 
Project Leadership enables top project managers to share their best practices and 
lessons learned with fellow practitioners across the Agency. 


When NASA managers, scientists, and engineers share their 
project stories, the Agency maximizes its return on 
investment by capturing experience-generated knowledge. 
Through conferences, workshops, and ASK Magazine, APPL 
cultivates a community of reflective practitioners. 

APPL's knowledge sharing services include: 

ASK Magazine 

APPL's bi-monthly journal shares knowledge about 
project management through storytelling. Stories by 
veteran project managers inside and outside the Agency 
capture the triumphs and challenges of projects large 
and small— sharing best practices and lessons learned in 
an engaging format. 

Forum of Master Project Managers 

NASA recognizes the accomplishments of many of its 
top project managers with an invitation to APPL’s twice- 
yearly Masters Forum. Project managers engage in 
small- and large-group discussions, and learn from 
fellow practitioners invited to tell stories about their 
experiences working on high-profile projects. In 
addition, experts from other Federal Agencies, academia, 
and industry share their innovative, successful 
approaches to project management. The Masters Forum 



is a unique opportunity for project managers from all 
NASA Centers and Enterprises to engage in face-to-face 
dialog as they share knowledge across the Agency. 

Transfer Wisdom Workshops 

At one-day workshops hosted by individual Centers, 
project managers and team members engage in small- 
group discussions of stories written by top NASA project 
managers. An APPL team facilitates the discussions, as 
practitioners apply the stories to the challenges of their 
own work. 

Through conferences, workshops, 
and ASK Magazine, APPL cultivates a 
community of reflective practitioners. 

Knowledge Sharing Workshops 

Because knowledge sharing isn't a one-day event, APPL 
offers a follow-up program to the Transfer Wisdom 
Workshops. At half-day Knowledge Sharing Workshops, 
Center practitioners continue to learn from the stories of 
veteran managers, as they share their own experiences 
and develop as mature practitioners. 

Project Management Shared Experiences Program 

NASA project managers, engineers, and scientists, as well 
as senior executives from industry and international 
agencies gather at this annual conference to share 
project management initiatives and approaches, as well 
as best practices and lessons learned. NASA attendees are 
generally Level 3 and 4 project managers. PMSEP 
reinforces the Agency's goal to be recognized as a world- 
class learning organization. 

Leaders as Teachers & Mentors 

This APPL initiative leverages the knowledge and 
experience of an identified set of current and retired 
Agency leaders and experts into a community of 
practice. The program gives formal recognition to 
leaders who give back to the Agency by sharing their 
expertise through guest lecturing, teaching, consulting, 
and mentoring. 


To learn more about about Knowledge Sharing and other APPL services, 
find contact information at www.appl.nasa.gov. 
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